------------------
[큰 원인 줄기 분석]
------------------
가장 깊은 upstream 원인은 Stage 1의 legal_calculation_object 설계가 문서 단위 1개 스냅샷이라는 점입니다. Stage 1은 문서마다 legal_calculation_object를 0개 또는 1개만 허용하고, 이후 Fact Ledger/claim view에서 linked evidence의 그 객체를 각 fact에 다시 병합합니다. 그런데 등기부 같은 문서는 원래 여러 개의 법률행위를 담습니다. 그 결과 성수동 토지 등기부(E-013)는 2024-10-05 매각/근저당 설정 스냅샷 1개만 남았고, 그 값이 2023-01-06 근저당 설정(F-012), 2023-04-06 증여(F-014), 2023-07-06 근저당 설정(F-016)에도 역류했습니다. 신림동 상가 등기부(E-014)도 2023-03-17 소유권이전/매매가액 스냅샷이 2022-04-18 근저당 설정(F-006)에 섞였습니다. 이건 단순 오타가 아니라, 다사건 문서를 단사건 객체로 압축한 설계적 오염입니다. 이 오염이 생기면 Stage 2는 근저당·증여·변제·경매의 인과사슬을 정확히 잡기 어렵습니다.


그 다음으로 큰 원인은 결정적 BO/fact가 빠졌다는 것입니다. client_meeting에는 “강용원이 2024. 7. 5. 4억 원을 변제했는데도 오민한이 담보권실행 경매를 신청했다”는 성수동 핵심 사실이 있고, 또 “박성희가 2024. 11. 20. 대지 임차·건물 매수 대금 전부를 지급하고 둘 다 인도받아 현재까지 점유한다”는 현재 점유 사실이 있습니다. 그런데 BO/Fact 계층에는 오민한의 경매신청 BO가 없고, 박성희의 인도·현재점유 BO도 없습니다. 대신 BO는 바로 이문호의 경매취득(bh29), 대한은행 근저당(bh30), 이문호의 신축(bh33), 박성희의 임차(bh34)·매수(bh35)만 남겼습니다. 즉, “누가 잘못 경매를 걸었는가”와 “누가 지금 점유하는가”라는 소송상 결정적 포인트가 구조화에서 탈락했습니다.


이 문제는 evidence_event_candidates.json의 희박성으로 더 심해졌습니다. 실제 산출물에는 E-001, E-006, E-017 세 문서만 사건행위 후보로 올라와 있고, 성수동/평택/신림의 핵심 등기부나 감정자료 대부분이 event layer에 들어오지 않았습니다. 특히 성수동 대지의 차임 시세를 담은 감정평가 의견서(E-005)는 downstream 이벤트층에 아예 올라오지 않아, 부당이득의 금전적 앵커가 사라졌습니다. 인간 변호사는 이런 시세 자료를 바로 “점유사용이익 반환”으로 연결하지만, 현 파이프라인은 “사건행위” 중심이라 그 연결고리가 끊겨 있습니다.


또 하나 중요한 점은, 현재 Stage 2 프롬프트는 오히려 꽤 좋은 규칙을 갖고 있다는 것입니다. client_meeting.md -> client_goal.json -> claim_identification_view.json 순으로 읽고, 구조화된 party/claim/date 필드를 우선하며, 복수 원고·복수 피고는 [원고]×[피고]로 분해하라고 지시합니다. 그런데 실제 출력은 C-002/C-005에서 원고를 묶어버렸고, C-010에서는 현재 점유자 박성희보다 과거 건축자 이문호 쪽으로 청구를 붙였습니다. 즉, 이번 차이는 “프롬프트가 나빠서”만이 아니라, LLM이 프롬프트의 핵심 통제 규칙을 충분히 따르지 못한 실행 실패도 포함합니다.


--------------
[개별 원인 분석]
--------------

C-002와 C-005에서 강용원이 원고에 들어간 이유는, 이 사건에서 상속 후 권리귀속을 확정해 주는 구조화 fact가 없기 때문입니다. BO에는 강호연의 사망(bh25)과 자녀들의 상속포기(bh28)는 있지만, 그 다음 단계인 **“누가 어떤 비율로 평택시 빌라 권리를 승계했는가”**가 fact로 정리되어 있지 않습니다. 그러니 Stage 2는 이를 정교하게 계산하지 못하고, client_meeting의 “강용원과 양정숙이 박광윤에게 통지서를 보냈다”, “의뢰인들은 박광윤을 퇴거시켜 빌라를 돌려받고자 한다”는 공동 행위 서술을 따라 두 사람을 공동원고로 넓게 잡았습니다. 그래서 이것은 무근거 환각이라기보다, 상속·원고적격 구조화 실패가 낳은 과잉포섭에 가깝습니다. 반대로 변호사는 소장 실무상 양정숙 1인으로 정리했을 가능성이 높지만, 그 부분은 문서만으로 확정할 수 없고 전략 판단의 영역입니다.


C-006은 명백한 오식별입니다. C-006은 F-023(강용원의 4억 변제)와 F-029(이문호의 경매취득)만으로 오민한 상대 손해배상청구를 만들었습니다. 그런데 client_meeting의 핵심은 “변제받고도 오민한이 경매를 신청했다”는 사실인데, 그 행위가 BO/fact로 빠져 있습니다. 그래서 Stage 2는 “변제 직후 경매로 소유권 상실”이라는 시간적 연쇄만 보고, 중간의 법적 행위(오민한의 경매신청·유지)를 구체적으로 포착하지 못한 채 generic한 손해배상으로 미끄러졌습니다. 즉, 불법행위 fact의 부재를 generic damage claim으로 메운 것이므로, 이 부분은 전략 차이가 아니라 엔진의 진짜 오류입니다.


C-010이 이문호 상대 건물철거·토지인도청구로 나온 이유는, 엔진이 “현재 권리침해 상태”가 아니라 “역사적 행위자”를 기준으로 체인을 잘랐기 때문입니다. client_meeting상으로는 이문호가 건물을 신축한 뒤, 박성희가 같은 날 대지 임차·건물 매수를 하고 둘 다 인도받아 현재까지 점유합니다. 인간 변호사는 그래서 현재 시점의 침해구조를 보아 박성희 상대 건물철거 및 토지인도로 정리합니다. 그런데 에이전트는 F-033(이문호 신축)을 기준으로 C-010을 만들고, F-034/F-035는 별도로 약한 퇴거청구 C-011로 분해했습니다. 다시 말해, 변호사의 6번 청구를 **C-010(이문호 상대로 철거·인도) + C-011(박성희 상대로 퇴거)**로 잘못 쪼개고 방향을 틀어버린 것입니다. 이는 “현재 점유자/현재 건물귀속자”를 잡아내는 구조화 fact가 없어서 생긴 전형적인 defendant fixation error입니다.


변호사가 식별한 4번·5번(이문호/박성희 상대 부당이득반환청구)을 에이전트가 놓친 이유는 더 구조적입니다. 현 파이프라인은 “사건행위→청구” 방식이라서, 처분·등기·신축·임대차 같은 event는 잘 잡지만, 그 event들로부터 파생되는 병존적 구제수단 묶음은 잘 못 만듭니다. 인간 변호사는 성수동 클러스터를 보면 보통 말소계열 청구, 철거·인도 청구, 그리고 점유·사용에 따른 부당이득반환청구를 동시에 엽니다. 반면 에이전트는 성수동에서 취소/말소·퇴거·철거 쪽으로만 가고, “무단 점유·사용의 이익”을 독립 청구로 병렬 생성하지 않았습니다. 그 이유는 두 가지입니다. 첫째, 성수동 차임 시세 자료(E-005)가 event layer/BO로 올라오지 않아 금전 앵커가 사라졌고, 둘째, 박성희의 현재 점유 사실 자체도 독립 fact로 없기 때문입니다. 그래서 변호사가 보는 “점유사용이익 반환” 회로가 시스템 안에서는 열리지 않았습니다.


----------------
[전체 분석 요약]
----------------

정리하면, 이번 차이의 성격은 네 가지로 나뉩니다. (1) 전략적·과잉포섭형 차이: C-002/C-005의 강용원 포함. (2) 명백한 false positive: C-006. (3) 잘못된 상대방·구제형태 분해: C-010/C-011. (4) 명백한 false negative: 변호사 4번·5번 부당이득반환청구 누락. 그리고 그 배후에는 identified_claims 안에 후보청구를 함께 넣는 출력정책, 문서 단위 1개 legal_calculation_object, 핵심 BO 누락, 현재 점유/이익 회로의 구조화 실패가 있습니다.


재발 방지의 핵심은 세 가지입니다. 등기부·계약서 같은 다사건 문서는 document-level 1 snapshot이 아니라 event-level structured object로 쪼개고, 상속승계·경매신청·현재점유·인도·사용이익 같은 “청구 생성에 직접 필요한 상태사실”을 BO/fact로 강제 생성하며, 하나의 property cluster에서 말소/철거·인도/부당이득을 병렬로 열어 보는 remedy-bundle validator를 별도로 두는 것입니다. 이 세 가지를 고치지 않으면, 앞으로도 인간 변호사는 하나의 성수동 클러스터에서 4개 청구를 읽는데 에이전트는 그중 일부를 후보·오식별·누락으로 분산시킬 가능성이 높습니다.






